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(54) Method and device for performing secure transactions 



(57) A certificate validity verification engine is inte- 
grated into the logic of a secure token, in turn, making 
the use of a private key conditional upon the determina- 
tion that the certificate for the corresponding public key 
is valid at that particular instant in time. In this manner, 
the existence of a digital signature that is verified with a 



certificate implies that the certificate was valid at the 
time the signature was created. The verification of the 
certificate's validity by the relying party is unnecessary, 
as the signature could not have been created had the 
certificate been invalid. The validity of a certificate is 
communicated at the time the signature was created, 
rather than at the time the signature was verified. 
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Description 

BACKGROUND OF THE INVENTION 

1 . FIELD OF THE INVENTION 5 

[0001] The invention relates to certificates issued for 
the purpose of identification, and more specifically to the 
determination of a certificate's validity. 

2. DESCRIPTION OF THE PRIOR ART 

[0002] Traditionally, secure tokens are physically-se- 
cured, tamper-resistant devices intended to create dig- 
ital signatures, perform decryption, or otherwise perform 
operations using a private key or secret symmetric key. 
Tokens may be incorporated in hardware on a computer 
or may be integrated with mobile devices such as "smart 
cards" and wireless devices. The cryptographic imple- 
mentation and the key material is enclosed in a secure 
shroud such that the correct operation and usage of the 
key can be assured. Typically, that the key will only be 
used upon presentation of an appropriate PIN or pass- 
phrase. The key is generally used only for approved se- 
cure operations, and the construction of the token is 
such that this key will not be disclosed outside of the 
secure shroud, and thus it cannot be copied. Often a 
secure token includes a signing engine and a private 
key, a, for which the public key is A. The public key has 
been certified by a Certificate Authority (CA), which has 
issued the certificate C A . The token is in communication 
with an application that makes use of the token for the 
creation of digital signatures, decrypting data, and the 
like. The application communicates a request to the 
cryptographic engine in the token, along with a PIN or 
passphrase, and the cryptographic engine executes the 
request using the private key. The request may be to 
sign a message, to decrypt an encrypted message, or 
some other request which would require the use of the 
private key. For each request posed by an application, 
a CA must assess the validity of that request, and there- 
fore thr validity has to be assessed at the originating and 
receiving ends. 

[0003] The public key infrastructure (PKI) has proven 
to be a secure mechanism for distributing keys and bind- 
ing attributes to those keys in a trusted manner. It is in- 
tended to bind an identity to a public key such that the 
holder of the corresponding private key is known to be 
of a particular identity. In order to accomplish this task, 
certificates are issued which is a document that binds 
an identity to a public key. This binding is enforced, gen- 
erally by a digital signature of a Certificate Authority. A 
CA is a trusted entity, trusted to provide certificates that 
bear signatures to individuals and entities that are able 
to verify their identity. A group of members that place 
trust in a common CA forms a public key infrastructure. 
When a pair of members in a PKI wish to communicate, 
they must verify the authenticity of each other's certifi- 



cates. The difficulty however, is introduced when trying 
to determine if a certificate is valid on an ongoing basis 
and, in turn, when to reject a revoked certificate. Pro- 
posed methods to overcome this difficulty fall into sev- 
eral categories; namely short-lived certificates, on-line 
status, and revocation lists. 

[0004] Short-lived certificates issued are valid for only 
a short period of time e.g./24 hours. These certificates 
are reissued regularly such that there is always a current 
and valid certificate. Relying parties do not need to verify 
the certificate's ongoing validity. If the security of a pri- 
vate key is compromised and reported to the certifying 
authority, the window of vulnerability ends when the cur- 
rent certificate expires and the certificate is not reissued. 
However, short-lived certificates require the certifying 
authority to reissue all of the outstanding certificates on 
a regular basis. This process can be computationally ex- 
pensive and requires automated, online access to the 
certificate-signing key. This, in turn, makes the process 
more vulnerable to attack than a CA which can keep its 
key off-line and/or less automated. Further, short-lived 
certificates have an inherent window of vulnerability 
from the time the private key is compromised until the 
time the certificate expires. In addition, regularly reissu- 
ing and distributing the certificates is expensive, difficult 
to scale to larger systems, and has a single point of fail- 
ure for the entire PKI. 

[0005] Another method to assure certificate validity is 
to assess the on-line status of a certificate each time 
that certificate is presented. On presentation of a certif- 
icate, the relying party requests the current validity of 
the certificate from the certifying authority. For efficien- 
cy, an implementation may include some caching such 
that the status of a certificate is only retrieved from the 
certifying authority if the last request for its status hap- 
pened long enough ago to be considered "stale," Check- 
ing the status of a certificate online requires each relying 
party to contact the CA or its designated representative 
each time a transaction is processed. Even with the 
availability of at least some caching of certificate validity, 
the number of queries is approximately one per trans- 
action per relying party. Further, few systems involve re- 
peated transactions with the same party. More often it 
is the case that each transaction is the first time a relying 
party has interacted with the certified party for a period 
of time, even in the case where either party is involved 
in transactions on an ongoing basis. Furthermore, the 
online status requires that all relying parties have the 
ability to contact the CA whenever they wish to validate 
a certificate. 

[0006] A third method to ensure the validity of certifi- 
cates is through the review of a revocation list. A revo- 
cation list details certificates that have been rendered 
invalid, e.g./ they have been revoked, and is kept by the 
certifying authority. The list is provided to relying parties 
and is updated on a regular basis and/or when new cer- 
tificates are revoked. A relying party reviews the revo- 
cation list to ensure that a certificate does not appear 
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on the list before accepting a certificate as valid. The list 
may take the form of a simple list of certificates or may 
be some other method of communicating the set of re- 
voked certificates. Revocation lists, in some situations, 
may become sizable where there are many revoked cer- 5 
tificates. Further, the lists must be reissued on a regular 
basis and distributed to the relying parties. In addition, 
revocation lists only describe the validity of a certificate 
at the time they are issued. When a certificate is re- 
voked, the revocation information will not be available w 
to the relying party until the regularly scheduled update 
of the CRL If the CRL is updated before its regularly 
scheduled time, the relying party must contact the CA 
for confirmation that its local CRL is up to date. This de- 
volves into having the same performance characteris- is 
tics as checking the certificate's status online. 
[0007] Most certificate validity assertions from certifi- 
cate authorities, such as online certificate status mes- 
sages or certificate revocation lists, bear signatures 
from the CA or some entity authorized by the CA to issue 20 
certificate status. This signature is necessary to indicate 
the accuracy of the information. Even a statement such 
as The current CRL has not changed; there is no sub- 
sequent update" must be signed. Furthermore, to pre- 
vent replay attacks, most status messages must be 25 
signed for by each requestor. Protocols are designed 
such that the requestor is certain that the message was 
signed specifically for them, and is not a stale message 
being replayed by an attacker. This can create a very 
high computational and communication burden on the 30 
CA and its authorized representatives. The result is a 
system that is not particularly scalable. 
[0008] With existing methods, as described above, 
the validity of a certificate is determined by the relying 
party at the time of reliance on a certificate and is thus 35 
subject to any error windows resulting from a delay in 
updating validity information. This can lead to both pos- 
itive and negative errors. In the case where a relying 
party is sending a message, the relying party deter- 
mines that a certificate is valid, encrypts the message, *o 
and sends it. At some later point, the private key of the 
recipient is compromised and the recipient's certificate 
revoked. However, all existing encrypted messages 
may-still be-decrypted, even though the certificate is no 
longer valid. Further, in the case where a user generates 45 
a valid signature using their private key, if that private 
key is later compromised and the certificate is revoked, 
the signature can no longer be validated, even though 
it was generated correctly and securely. The problem 
resides in the fact that the validity of a certificate controls 50 
the use of the public key since it is consulted by relying 
parties who are about to use a certificate. However, the 
validity of a certificate also communicates the security 
of the private key in that a certificate is revoked when 
the holder of the private key can no longer be associated 55 
with the identity or privileges communicated in the cer- 
tificate. 

[0009] It is an object of the present invention to obvi- 
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ate and mitigate at least some of the aforementioned 
disadvantages of the prior art. 

SUMMARY OF THE INVENTION 

[0010] It is accordingly a principal objective of the 
present invention to establish a system for the validation 
of a certificate's authenticity at the time of private key 
usage. 

[001 1] In general terms, this invention provides a sys- 
tem for facilitating the validation of an issued certificate, 
and further, enables the relying party to process a cer- 
tificate, knowing the certificate to be valid without inde- 
pendently scrutinising its validity. The system comprises 
a cryptographic engine, a validation engine, at least one 
interface to a certificate authority, and an independent 
application. The application communicates a request to 
the cryptographic engine within a secure token along 
with a personal identifier. The secure token further in- 
cludes a signing engine and private key H a" for a known 
public key "A". The cryptographic engine executes the 
request using the private key. On each request from the 
application to utilize the private key "a" (for creating a 
signature, decrypting a message, or any other allowed 
purpose) the validation engine is invoked. The validation 
engine has the ability to allow or disallow the completion 
of the requested private key operation. On each such 
request, the validation engine determines whether a 
certificate is treated as valid at that moment or instant 
in time and operates accordingly. 
[0012] A request, such as a signature, is only gener- 
ated (or a message is decrypted) only if the certificate 
continues to be valid. Thus a relying party utilizing the 
private key of certificate C A does not need to make an 
independent determination of the certificate's validity. In 
the case of a signature, the existence of a signed mes- 
sage implies that the certificate was valid at the time the 
signature was created and thus, that such a signature 
is treated as acceptable. This determination does not 
require that the relying party contact the certification au- 
thority, as the validation engine associated with the pri- 
vate key has performed that task. Similarly, when the 
relying party generates an encrypted message intended 
for the holder of certificate C A , they are secure in the 
knowledge that the message may only be decrypted if 
the certificate is valid at the time of decryption. 
[0013] By operating in this manner there is the addi- 
tional advantage of determining validity of a certificate 
at the time of private key usage, as opposed to the time 
of certificate reliance. Using a token incorporating a va- 
lidity engine, the validity of a certificate controls the use 
of the private key, and as such, binds the meaning of 
certificate revocation to the effect of the revocation and, 
in turn, prevents further use of a certified private key. 
[001 4] In order to securely communicate to the relying 
party that there is no need for the recipient to verify the 
validity of the certificate a certificate extension signed 
by the CA is added when the CA issues a certificate. 
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Thus, when a relying party processes a certificate with 
this extension, they are aware that it is not necessary to 
independently check the validity of the certificate. If a 
certificate does not have such an extension, the validity 
of a certificate cannot be assumed without independent- 5 
ly verifying its validity. 

[001 5] The validation engine may further determine rf 
the utilization of private key Vis consistent with a par- 
ticular policy associated with the use of that private key. 
The policy is customizable by the end user. If the certif- 
icate is valid and the key usage is appropriate, the pri- 
vate key operation is allowed to complete; if not, the pri- 
vate key operation is terminated. The validation engine 
operates in such a fashion that its determination as to 
the validity of a certificate is secure against tampering 
and interference by any party controlling the token or 
the token's communications channels with the outside 
world. This is especially true of communication channels 
with parties who may assist the validation engine in its 
determination as to the certificate's validity. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[001 6] These and other features of the preferred em- 
bodiments of the invention will become more apparent 
in the following detailed description in which reference 
is made to the appended drawings wherein: 

Figure 1 is a is a schematic diagram of an overview 
of a computer system; 

Figure 2 is an expanded view of the secure token 
of Figure 1 ; 

Figure 3 is a further detailed view of Figure 2; 
Figure 4 is a functional block diagram detailing the 
method for establishing a certificate for use in the 
validation of a request between a pair of nodes on 
a public key infrastructure, in the computer system 
of Figure 1 ; and 

Figure 5 is a further detailed view of Figure 3. 

DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 

[0017] A system for establishing the validity of a cer- 
tificate's authenticity is illustrated in Figures 1-5 and is 
generally designated by reference numeral 10. 
[0018] As shown in Figure 1, the system comprises 
an application 14 controlled by an originating corre- 
spondent 15, a recipient correspondent 18, and a cer- 
tificate authority (CA) 16, interconnected by communi- 
cation links 19 to a secure token 12. The secure token 
12, as shown in Figure 2, further includes a validation 
engine 20, a certificate 22, a cryptographic engine 26, 
and a private key 24 all stored within a secure boundary 
25. 

[0019] The system 10 enables an application 14 
(commanded by third party user) to communicate a re- 
quest to the secure token 12 by a link 19a. The request 



may be to sign a message, decrypt an encrypted mes- 
sage, or any other action that would require the use of 
a private key. On receipt of a request from the applica- 
tion 14, the secure token 12 communicates with the cer- 
tificate authority (CA) 16 over link 1 9b in order to assess 
the validity of the request. The certificate authority 16 
returns a message to the secure token 12 indicating the 
status of the certificate 22, and if the request is valid 
enables the token 12 to sign the message and append 
a certificate 22. The signed message and certificate 22 
is sent either to the application 14 or forwarded directly 
to the end user 18. Once the user 18 receives the cer- 
tificate 22, the user 18 may be assured that the certifi- 
cate authority 16 has validated the certificate 22 at the 
time of issue. Thus, there is no need for user 18 to au- 
thenticate the validity of the certificate. 
[0020] Figure 4 details the manner in which a signa- 
ture is validated using the system 10 illustrated in Fig- 
ures 1 and 2. The process begins with an application 14 
requesting a signature from the secure token 12 on a 
message, m. Upon receipt of the request, 102, the val- 
idation engine 20 within token 12 sends an inquiry at 
106 to certificate authority 16 to determine if the certifi- 
cate 22 is valid and may be appended. If the certificate 
22 has been revoked, authorization is not issued and 
the request is denied 108. If the certificate 22 is valid 
however, the certificate authority 16 returns an authori- 
zation to the secure token 12. The validation engine 20 
receives the authorization and enables the cryptograph- 
ic engine 26 within the secure token 12 to execute the 
original request 112, creating a digital signature utilizing 
the private key "a". Once the message is signed, the 
certificate 22 is appended and returned to the applica- 
tion 114. In turn the application 14 sends the certificate 
22 onto the user 116. In the alternative, the certificate 
22 is sent directly to the user 1 1 8. The transmission of 
the request and return of the authorization will be 
conducted in a secure manner utilizing public key 
protocols to ensure the authenticity of the request. 
[0021] The validation engine 20 within the secure to- 
ken 12 operates in such a fashion that once it deter- 
mines the validity of a certificate, the end user 18 is not 
required to also perform an independent validation. The 
validity of a certificate controls the use of the private key 
24 through the validation engine 20, and as such, binds 
the meaning of certificate revocation to the effect of that 
revocation. This prevents further use of a certified pri- 
vate key when a certificate 22 is revoked. In the case of 
a digital signature as described in Figure 4, a signed 
message would remain valid even after a certificate 22 
has been revoked, because the signature could not 
have been generated after the moment of certificate rev- 
ocation. In the case where a request is to decrypt a mes- 
sage, if the private key 24 is compromised (through theft 
of the token, etc.,) the certificate 22 is revoked and the 
secure token 12 would cease to honor requests to de- 
crypt messages, meaning that any existing encrypted 
messages could no longer be decrypted. 
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[0022] In the preferred embodiment, the ability to en- 
able the system 10 to avoid the user 18 from requiring 
an independent validity check is incorporated as an at- 
tribute of the certificate 16. 

[0023] In order to ensure that the user 1 8 is aware that 5 
the validity of the certificate need not be checked, an 
indicator mechanism is required. One way that this is 
achieved is by specifying a certificate extension 28 as 
shown in Figure 3. This certificate extension 28 is signed 
by the certificate authority 1 6, shown in Figure 1 , when 10 
a certificate 22 is issued and is appended only when au- 
thorization is received from the CA 16. Therefore, when 
user 18 processes a certificate having an extension 28, 
the user is aware that it need not independently check 
the validity of that certificate 22. In the case where a *5 
certificate 22 does not have such an extension, it can 
not be assumed valid without independently checking 
its validity. 

[0024] However, in an alternate embodiment, this at- 
tribute could be implicitly associated with the key pair. 20 
An implicit key pair association requires a mechanism 
or policy to prevent a CA from issuing a certificate to the 
key pair without that CA having some assurance that 
the secure token 1 2 hosting the private key 24 is check- 
ing the validity of the certificate issued by the CA on an 25 
ongoing basis, thus controlling the use of the private key 
based on that information. 

[0025] Prior to a CA 1 6 issuing a certificate 22 with an 
extension 28 that indicates that the private key is con- 
trolled in manner previously described, the CA must de- 30 
termine that the private key is held by a secure token 12 
that will enforce a validity checking policy. However, it is 
also desirable to allow the token 12 the ability to gener- 
ate a key pair and have that key pair certified while the 
token 1 2 is under the control of the end user. This ena- 35 
bles the end user to ensure total control over the use of 
the private key from the moment of its generation. 
[0026] In order to securely communicate to the end 
user that a private key 24 is stored in a secure token 12 
from the token 12 to the certificate authority 16, the to- *o 
ken 12 must "vouch" for the key. In the preferred em- 
bodiment the token 12 is given a secure secret key 30 
as illustrated in Figure 5. The token 12 uses it's own se- 
cure secret key 30 in order to attest that the private key 
"a" 24 for which certification is being requested has been 45 
generated within the secure token 12 and, in turn, that 
the use of the key 24 is controlled by the validation en- 
gine 20 within that token 12. Only the token 12 and the 
CA 16 may know the secure secret key 30, in one in- 
stance, or it may be a public key mechanism. However, 50 
in the case of a public key mechanism, the token has a 
private key which is either programmed in by the CA, or 
generated within the token such that the public key is 
recorded or certified prior to the token being delivered 
to the end user. Regardless, the key which authenti- 55 
cates the token is established, recorded, or certified pri- 
or to the certificate being delivered to the end user, such 
that it is known that the token has not been tampered 
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with, and, in turn, that the token authentication key is 
authentic. 

[0027] The secure token 12 attestation is accom- 
plished prior to delivery to the end user in a secure do- 
main. The secure token 12 is asked to generate a key 
pair comprising the token secure key 30 and a corre- 
sponding public key. it stores the private key secure and 
within the token, using it only in the token attestation 
process. The corresponding public key is taken and cer- 
tified by a CA. This CA may be a public CA, one con- 
trolled by the token's manufacturer, or some other au- 
thority. By issuing the certificate, the CA attests that the 
private key is controlled by a token 12 that prevalidates 
the certificate. The attestation certificate is stored within 
the token 12 as indicated at 32. Presumably, in order to 
make this attestation, the token 12 will have to be phys- 
ically within a secure facility in order for the CA to be 
sure that it is certifying a correctly obtained public key. 
[0028] Once the token 12 has secure key 30 and an 
associated certificate 22 stored within, it is delivered to 
the user. The end user 18 asks the token 12 to generate 
a key pair for ongoing use, which it does. Then, the end 
user 18 asks the token 12 to request a certificate 22. 
The token 12 generates a certificate request and au- 
thenticates this request via its token attestation key 30. 
In this case the token 12 acts as an initial registration 
agent: it signs the certificate request data with its secure 
key 30 to attest to its validity and its origination within 
the token 12, then appends its own certificate 32. The 
registered request can then be forwarded to the CA. Up- 
on receiving this request, the CA can validate the to- 
ken's attestation certificate (including possibly inde- 
pendently checking whether the token's certificate is still 
valid) and its signature on the certificate request data. 
When the checking procedure succeeds, the CA issues 
a certificate 22 with the knowledge that the private half 
of the key pair being certified is securely held within a 
token 12 which will determine the validity of the certifi- 
cate before the private key 24 can be used. The CA ap- 
pends an extension 28 to the certificate 22 indicating to 
the end user that a relying party need not independently 
check the revocation status of the certificate. 
[0029] In addition to validating the current status of a 
certificate before allowing a private key operation to pro- 
ceed, the validation engine may also ensure that the use 
of the private key is conformant with a particular policy. 
That policy is customizable to a specific end user of 
group of users such as a corporation. The policy is typ- 
ically stored in the certificate however, it may be asso- 
ciated in some other manner. For example, a particular 
key may only be approved for use in signing messages, 
and not decryption. Complex policies could be created 
and enforced, potentially making use of external com- 
munication. A secure token issued to a corporate certif- 
icate authority could enforce a policy which would only 
allow the private key to be used to sign certificates for 
employees of that company who appear on some mas- 
ter list, or who are approved by some other server. Such 
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a policy would control the use of the key, the profile of 
the certificates to be signed, the contents of some fields 
of those certificates, and validating information from oth- 
er fields in those certificates against an external data 
source. Similar policies could be created regarding the 5 
disposition of data that is decrypted using the private 
key. 

[0030] There is a plurality of mechanisms that the to- 
ken 12 may use to determine if a certificate is valid. The 
token 12 often acts as a relying party and utilize an on- 10 
line certificate status mechanism or a certificate revoca- 
tion list. As an efficiency mechanism, the token need not 
consult a CA for every use of the private key. Instead, 
the token caches the validity information and verifies 
that information on a periodic basis. The period of time * 5 
elapsed between information verification, may be as 
high as once a second, for an extremely high value key, 
but may be more likely on a longer interval. The interval 
would have some relationship to the risk borne should 
the key become compromised. This time period is cus- 20 
tomizable by the end user. 

[0031] The use of a validation engine within a token 
facilitates the scalability of the overall system. It replac- 
es many clients, which individually request certificate 
status with a single centralized point requesting such 25 
status. Further, the validation engine may reduce the 
computational load on a certificate status provider by us- 
ing symmetric cryptography to verify status responses. 
In this embodiment, the system employs a protocol like 
SSL, such that the token 12 negotiates a secure con- 30 
nection with the certificate status provider. A connection 
consists of a handshake phase that uses public-key 
cryptography to establish a shared secret key known to 
both ends of the connection. Thereafter, individual mes- 
sages passed over the connection are authenticated, 35 
and optionally encrypted, using keys derived from this 
shared secret. Such symmetric operations are more ef- 
ficient than digital signatures and public-key encryption 
operations that would be required to individually encrypt 
and authenticate each message. *o 
[0032] A token typically issues repeated requests for 
certificate status, and these requests place a large com- 
putational load on both the token itself and the CA. This 
load is greatly reduced by negotiating a secure connec- 
tion, in which the certificate status provider is authenti- 45 
cated as a trusted provider of certificate status informa- 
tion. Thereafter, certificate status queries and respons- 
es can be sent over the secure connection, each being 
symmetrically authenticated with the shared secret key 
negotiated in the handshake phase of establishing the 50 
secure connection. In protocols such as SSL, these 
symmetrically authenticated messages may be trans- 
mitted over several connections, each deriving its keys 
from a single shared secret established in an initial 
handshake. This use of a secure connection instead of 55 
individually authenticated messages gains a perform- 
ance advantage by leveraging a single public key oper- 
ation (in the handshake) into authenticating several or 
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many different certificate status request/response pairs. 
This is at the cost of those certificate responses no long- 
er being individually authenticated in such a fashion that 
they could be presented to third parties for verification. 
[0033] In order to communicate with the certificate au- 
thority or its designated agent, the token in some cases 
requires access to an external network. In the preferred 
embodiment, a helper application runs on the computer 
that hosts the token (assuming that the token is an ex- 
pansion card or some other such device which does not 
have direct access to network capabilities). Such a help- 
er application acts as a gateway between the token and 
the service(s) it requires on the network, conveying data 
back and forth. The endpoint of ail secure communica- 
tions with the certificate status providers must be within 
the secure shroud of the token; this means that the help- 
er application can serve as a conveyer of data to and 
from the token, but cannot serve as the endpoint for se- 
curity protocols (such as SSL). 
[0034] The verification engine prevents use of a pri- 
vate key unless a certificate status provider can be con- 
tacted and a positive assertion about the current validity 
of the certificate is attained. Therefore, the reliability of 
the network connections between the token, its hosting 
computer, and the certificate status provider are of par- 
amount importance to the ongoing reliability and avail- 
ability of the service being provided by the token's pri- 
vate key. Thus, it is of great value to have multiple, re- 
dundant, and independent mechanisms for the token to 
contact the certificate status provider or providers. 
[0035] The certificate extension informing the relying 
party that a private key is protected with a certificate val- 
idation engine may further include a mechanism to com- 
municate to the relying party what the parameters this 
protection includes. For example: 

• The physical protection level of the token (for exam- 
ple, FIPS 140-1 level 1, 2, 3, or 4). 
The frequency of validity checks performed by the 
validation engine (for example, whether the CA is 
contacted for every transaction, every minute, hour, 
day, or some other period). 
What other policies are enforced by the validation 
engine (for example, around the allowed use of the 
key or the validation of the actual messages 
signed). 

[0036] In addition to refusing the use of the signature 
engine upon determination that the CA has not allowed 
such usage, the token could choose to take other ac- 
tions, such as zeroizing (destroying) the private key or 
rendering the token unusable. 

[0037] A token incorporating a certificate validation 
engine protects against several validity problems that 
periodically occur in a secure environment. Under some 
circumstances, the security of the key is betrayed. In a 
secure token, this is generally coupled with the physical 
security of the token being betrayed or the software us- 
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ing the token becoming insecure. For example, a server 
containing a physically secured token maybe stolen, 
giving the thief control of the token. In another example, 
a server containing such a token could be compromised 
by a hacker in such a way that the server's authorized 
operators are no longer certain that the token was only 
being used in an authorized fashion. In either case, re- 
voking the certificate assigned to the token would cause 
the validation engine in the token to halt all further use 
of the token's private key. Another such use is the case 
of an incorrectly issued certificate. For example, a CA 
issues a certificate and then find that the papers used 
to identify the certificate requestor were forged. In this 
case, the CA revokes the certificate that was issued and 
the token halts all further use of the certified private key. 
[0038] Similarly, revocation is also used to manage 
ongoing validity issues. For example, a certificate is- 
sued to a party under some terms or conditions which 
become invalid at some later point, the recipient of the 
certificate fails to pay their maintenance fees. In such a 
case, the CA revokes their certificate, halting further use 
of the key by the token. 

[0039] The substantial benefit of a token incorporating 
a verification engine is that it obviates a need for the 
relying party to check the revocation independently. This 
is of particular benefit in situations where a set of relying 
parties have been deployed which do not check revo- 
cation, such as in the case of Internet web browsers im- 
plementing the SSL protocol. Most such browsers will 
not check with a certificate authority to determine that a 
certificate has been revoked. In such a case, should a 
certificate be revoked for any reason, such revocation 
will not have any practical effect on clients using prior 
art devices which do not check that revocation. Howev- 
er, when using a token incorporating a verification en- 
gine, the effect of the revocation is assessed at a single 
point. The use of the private key corresponding to a cer- 
tified public key is based on the ongoing validity of the 
certificate. The result being that it eliminates the need 
for relying parties to verify the current validity and, in 
turn, increases the security of a system where many 
such clients checking certificate validity. 
[0040] In addition, enforcement of additional policies 
with respect to the use of the key protects the certificate 
authority against malicious or accidental misuse of the 
key. For example, a policy could enforce certain aspects 
of certificate issuance by a subordinate certificate au- 
thority. Thus, the superior certificate authority has con- 
fidence that the appropriate use of the subordinate cer- 
tificate authority is enforced technologically at the point 
of use ofthe private key, rather than relying on legal 
agreements or complex validation procedures by the re- 
lying party. 

[0041] A token incorporating a certificate validation 
engine is able to manage a number of private keys with 
their corresponding certificates. The token contacts a 
number of different certificate authorities to determine 
the validity of these various certificates to control the us- 



age of their associated private keys. Generally it is in- 
appropriate to have multiple certificates certifying the 
public key of a particular key pair. Such a circumstance 
would typically require the token to determine that ail 

5 these certificates continued to be valid in order to use 
the private key. However, incorporating a validation en- 
gine into a token enable the system to verify only the 
validity ofthe certificate which is being used in that par- 
ticular instance. 

10 [0042] Although the invention has been described 
with reference to certain specific embodiments, various 
modifications thereof will be apparent to those skilled in 
the art without departing from the spirit and scope of the 
invention as outlined in the claims appended hereto. 

15 

Claims 

1 . A computer system for establishing a certificate for 
20 use in the validation of a request sent between a 

pair of correspondents on a public key infrastruc- . 
ture, the system comprising: 

an application located at one of said corre- 
25 spondents, said application generating a re- 

quest; 

a secure token in communication with said ap- 
plication, said secure token including a valida- 
30 tion engine, a cryptographic engine, a certifi- 

cate, and a private key; and 

a certificate authority; 

35 wherein said secure token receives said request 
from said application, authenticates the validity of 
said request through said certificate authority, said 
certificate is signed by said cryptographic engine 
using said private key, and said signed certificate is 

40 sent to a correspondent, where said certificate is 
known to be valid by said receiving node. 

2. The computer system of claim 1 , wherein said val- 
idation engine is invoked on each request to utilize 

45 said private key of said secure token. 

3. The computer system of claim 1 , wherein said cer- 
tificate includes a certificate extension as a mech- 
anism to indicate to said receiving node that said 

so certificate is known to be valid. 

4. The computer system of claim 1, wherein said se- 
cure token farther includes a secure key, 
wherein said secure key is used to attest to the va- 

55 ijdity of said private key within said secure token and 
said private key is controlled by said validation en- 
gine each within said secure token. 
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5. The computer system of claim 1 , wherein said val- 
idation engine enables the system to ensure said 
private key within said secure token is conformant 
with a specified policy. 

5 

6. The computer system of claim 1 , wherein the valid- 
ity of said certificate controls the use of said private 
key. 

7. A method for establishing a certificate for use in the 10 
validation of a request sent between a pair of nodes 

on a public key infrastructure, the method compris- 
ing the steps of: 



a) generating a request by an application locat- * 5 
ed on said node; 

b) sending said request to a secure token; 

c) analyzing of said request by a validation en- 
gine located within said secure token; 

d) sending said request to a certificate authority 20 
by said validation engine; 

e) generating a certificate by said certificate au- 
thority ensuring the validity of said request; 

f) receiving said certificate by said secure to- 
ken; 25 

g) executing said request by a cryptographic 
engine within said secure token using a private 
key located within said secure token, where 
said private key is associated with said certifi- 
cate authority; 30 

wherein the validity of said certificate is known to 
an intended receiving node. 

The method of claim 7, wherein said certificate fur- 35 
ther includes a certificate extension signed by said 
certificate authority, and where said extension iden- 
tifies to a receiving node the validity of said certifi- 
cate. 



The method of claim 7, wherein said token further 
includes a secure key such that on a request by an 
application said secure key attests to the validity of 
said private key located within said secure token. 



40 
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